1. Field of the Invention
The present invention relates generally to transaction management in a distributed object computing environment, and more particularly, to a method for using a transaction service synchronization interface to perform container internal state clean-up after a transaction has completed.
2. Description of the Related Art
The Common Object Request Broker Architecture (CORBA), an industry standard established by the Object Management Group (OMG), is designed to provide object-oriented, distributed computing standardization and interoperability. One aspect of the CORBA standard relates to transaction management, which ensures that transactions are properly handled across an object-oriented distributed system. Specifically, the Object Transaction Service (OTS) Specification, version 1.1, November 1997, herein incorporated by reference, specifies the transaction services requirements. In a CORBA compliant system, a transaction is viewed as a unit of work having the following characteristics:
A transaction is atomic; if interrupted by failure, all effects are undone (rolled back).
A transaction produces consistent results; the effects of a transaction preserve invariant properties.
A transaction is isolated; its intermediate states are not visible to other transactions. Transactions appear to execute serially, even if they are performed concurrently.
A transaction is durable; the effects of a completed transaction are persistent; they are never lost (except in a catastrophic failure).
The OTS 1.1 Specification defines interfaces that allow multiple, distributed objects to cooperate. In particular, each transaction is xe2x80x9catomicxe2x80x9dxe2x80x94that is, each transaction is either completed (all changes committed) or the changes are rolled back. The defined interfaces enable objects to either commit all the changes or perform a rollback. One interface defined by the specification is the Synchronization Interface. The Synchronization Interface allows different system resources participating in transaction to be notified that transaction is about to complete (or xe2x80x9ccommitxe2x80x9d), and therefore the resources can flush out any transient data to a database (i.e. store the data).
An object with transient state data is notified by the Transaction Service through the Synchronization Interface prior to the completion of a transaction, in order to flush any transient data to storage (i.e. the transient data is made xe2x80x9cpersistentxe2x80x9d). This notification is performed by a xe2x80x9cbefore_completionxe2x80x9d operation. After the transaction has completed, the Transaction Service invokes an xe2x80x9cafter_completionxe2x80x9d operation. An example of the syntax for these operations is shown in FIG. 1.
One problem posed by distributed transaction processing is that each portion of a distributed transaction may not be aware of when the transaction actually completes. As a result, temporary memory space used for the transaction may not be cleaned up after the transaction processing has completed. Therefore, it would be desirable to have a mechanism to notify individual objects that a particular transaction has completed and that any associated memory space may be cleaned (i.e. reallocated for use).
The present invention is a method for using a Synchronization Interface in a computer system compliant with a CORBA Object Transaction Service or the Java Transaction API (such as Java 2 Platform Enterprise Edition Reference Implementation) to perform internal state clean up in containers associated with a completed transaction. First, a synchronization object is registered for each new transaction in a container with a Transaction Manager compliant with either OTS or JTA. The Transaction Manager detects a completion of the transaction and then invokes an xe2x80x9cafter_completionxe2x80x9d operation (method) on the synchronization object. This notifies each container involved in the completed transaction to perform internal memory space clean up.
Thus, the method uses an existing Synchronization Interface mechanism (originally designed to flush transient data to storage) to perform internal memory state clean up in containers. Since the Transaction Manager does not need to have specific knowledge of the container, no modifications are needed to the Transaction Manager. Also, since the Transaction Managers already cooperate among themselves, there is no need to create a whole new communication mechanism, which would add complexity and inefficiency.